home *** CD-ROM | disk | FTP | other *** search
- Path: news.eunet.fi!fipnet!kone!jsaarinen
- Newsgroups: comp.sys.amiga.programmer
- X-NewsReader: IntuiNews 1.2b (31.7.94)
- References: <38231986@kone.fipnet.fi> <judas.0hi3@tomtec.abg.sub.org>
- From: "Jyrki Saarinen" <jsaarinen@kone.fipnet.fi>
- Date: Tue, 23 Jan 96 15:56:14 UT
- Comments: Illegal date header - new date added by quicknews
- X-Original-Date: Mon, 22 Jan 96 23:50:19
- MIME-Version: 1.0
- Content-Type: text/plain; charset=iso-8859-1
- Content-Transfer-Encoding: binary
- Distribution: world
- Subject: Re: Serial Cable
- Message-ID: <38232131@kone.fipnet.fi>
-
-
- > On the ECS there a bit called BLTPRI, found in DMACON. Setting this bit
- > means to give the blitter priority over the CPU in case of chipram access.
- >
- > Making the blitter busy enough, makes any access to chipram from the CPU
- > delayed until the blitter has finished its operation.
-
- This is the case even without BLTHOG bit turned on, chip ram
- memory bandwidth is lower when blitter is active. I have noticed
- it as are many others.
-
- > As the BLitBusyBit was somehow buggy on prior chipsets, some programmers
- > found an other solution.
-
- Why they did not read the few lines what HW Manual tells how
- to wait the blitter. Besides, that situation occurs really
- rarely..
-
- ---cut---
- Because of a bug in Agnus (prior to all revisions of fat Agnus)
- this code may return too soon when the blitter has, in fact, not
- started the blit yet, even though BltSize has been written.
-
- This most often occurs in a heavily loaded system with extended memory,
- HIRES, and 4 bitplanes.
-
- WaitBlit currently tries to avoid this Agnus problem by testing
- the BUSY bit multiple times to make sure the blitter has started.
- If the blitter is BUSY at first check, this function busy waits.
-
- This initial hardware bug was fixed as of the first "Fat Agnus" chip,
- as used in all A500 and A2000 computers.
-
- Because of a different bug in Agnus (currently all revisions thru ECS)
- this code may return too soon when the blitter has, in fact, not
- stopped the blit yet, even though blitter busy has been cleared.
-
- This most often occurs in a heavily loaded system with extended memory,
- in PRODUCTIVITY mode, and 2 bitplanes.
-
- WaitBlit currently tries to avoid this Agnus problem by testing
- the BUSY bit multiple times to make sure the blitter has really
- written its final word of destination data.
- ---cut--
-
- > To go sure the blitter has finished, you just access chipram.
- > (naaaahh, don`t tell me about waitblit() .. =)
-
- What? How the hell blitter state can be tested by accessing
- chipmem?
-
- > As the AAchipset allows access to chipram, while blits are active, you
- > loose the syncronisation with the blitter.
- > (this also happens, when ECS-chipset is selected !!)
-
- Are you actually saying that on A500/2000 one cant access
- chipram while blitting?
-
- Syncronisation? Isnt it more like trashing the memory if blitter
- waiting fails?
-
- I have always wondered why some people did no blitter waiting,
- instead they did delay loops! What a brilliant idea!
-
- Instead of waiting the blitter correctly they decided to
- spend the same amount of time in a delayloop..
-
- -- _
- a Stellar programmer _ //
- "Amiga - back for the future" \X/
-